In today's competitive marketplace, providers of products are seeking to improve their financial performance by driving down costs, increasing revenue and ensuring continued customer satisfaction through rapid rollout of complex products, accurate and timely product provision and ongoing, robust service management. In some industries, such as the telecommunications industry, research has shown that inaccurate or delayed service activation, resulting from inefficient operations and manually-intensive processes, is a primary cause of low customer satisfaction. It is not uncommon to see orders for complex services experience an order fallout rate in excess of 80%. Therefore, a focus on continued customer satisfaction is extremely likely to yield an increase in financial performance. However, implementing this strategy has been difficult due to the complex and data-intensive processes required to provide accurate and timely products.
Computer automation offers the possibility of completely automating such complex processes. Some automation of these processes can be achieved through the use of pre-packaged applications or legacy systems. Pre-packaged applications are relatively inexpensive and easy to implement. However, pre-packaged applications often do not provide processes that fit the specific needs of a particular product, industry, or company. In addition, the processes offered by these pre-packaged applications are generally inflexible and therefore, very difficult to change with changing requirements. In contrast, legacy systems provide custom processes that are designed for a particular need. However, legacy systems are relatively expensive and time consuming to create and implement, and once implemented, may be just as inflexible as pre-packaged applications.
Neither pre-packaged applications nor legacy systems provide the flexibility needed to create processes for provisioning new products. Both these systems provide hard-wired solutions that need to be reprogrammed to reflect process changes. Further, neither pre-packaged applications nor legacy systems adequately address the issue that many processes can not be handled by a single application. For example, a process for fulfilling an order for products may require one application to capture customer information, another to capture the order itself, another to arrange for shipping the order, and yet another for billing the customer. In addition, applications may be needed for purchasing and inventory. More often than not, these different applications cannot communicate with each other, and information entered into one system generally needs to be reentered into each of the other systems. Further, neither pre-packaged applications nor legacy systems adequately address the issue that some processes include steps that require human intervention. For example, an order for a custom part or service usually requires that some portion of the process for fulfilling the order be addressed manually because the steps required for fulfilling a particular custom order may not be provided by the existing process.
In order to provide some customization and integration, the methodologies of business process management (“BPM”) have been used to automate processes for provisioning orders. As used in this document “order” refers to a request for products, including goods, services or a combination of goods and services. In addition, “provision” refers to the activities involved in and related to providing products to the entity that placed the order. While previous solutions, such as pre-packaged and legacy systems, were based on a document-centric approach, BPM is based on a process-centric approach. BPM separates the management of processes into an independent layer that is separate from the underlying applications. This “independent process layer” or “IPL” enables a view of all the activities necessary to execute a particular business process, and the management of these activities even if the activities involve different applications, people or both. The IPL may generally be created using a process management tool within a framework such as an enterprise integration (“EI”) framework.
In the IPL, processes may be created and stored. For example, if a BPM approach is used to implement a system for processing orders, separate processes for receiving the order, identifying the desired products, and providing each of the desired products may all be created in the IPL and stored. When an order is received from a customer and enters a BPM system, the IPL identifies the products included in the order, and selects from the stored processes those processes that are designed to provide the identified products to the customer. The processes are hardcoded into the BPM application.
Although process management tools using a BPM approach enable process automation that is more customizable than enabled by pre-packaged systems and less time consuming and expensive to implement than enabled by legacy systems, such tools do not supply the flexibility required to capture and implement processes as they change with time. Further, BPM systems may be quite inefficient. For example, to enable processes for provisioning products, the processes need to include steps designed to handle any product variation or circumstance that may arise. However, for a given order, not all the steps included in a given process may be needed.
Businesses, and therefore processes enabling business, change all the time and are becoming more volatile. Moreover, as the Internet and other networks are used to link systems, people and organizations together, longer, more complicated, integrated and dynamic processes are necessary. For example, it is very common for a product provider to periodically offer new products, and to discontinue or change existing products. If the provider uses a BPM system to provide these products, each time a new good or service is added, a new process for providing that product must be created and added to the IPL. Likewise, each time an existing product is changed, the process for providing that good or service must be changed in the IPL. Adding or changing the processes in a BPM system may require significant software reprogramming. Such programming can consume considerable time and resources, which negatively affects the efficiency, reliability and responsiveness of the BPM system. The need to reprogram software to accommodate process changes creates a particular technical problem requiring solution.